function widget:GetInfo()
	return {
		name = "MouseHandler",
		desc = "keep Mouse input doing the right stuff",
		author = "Sean Heron",
		date = "January 2009",
		license = "GNU GPL v2 or later",
		layer = 1,
		enabled = true
	}
end

-- okay - the broad structure of the below can probably be disregarded - instead we have the individual elements handle their stuff 
-- (still using the methods described below though)


function widget:MousePress() 	-- some parts of this approach might have to be adapted, if we have any moveable/expanding or popup GUI elements whatsoever. Might want to think about that before we need it :D.
														-- obviously we can make this arbitrarily complex - but KIS for the moment
	if Mouse between these two  x-values [and perhaps also between two y values, or perhaps even within a triangle or two (hmm, connecting requirement possible??) then
		-- its in the "play" (ie Engine rendered rather than GUI-image) area
		
		-- so do stuff like - as long as no "order" or ability is selected, all left clicks are attack orders. And all right clicks, perhaps switch between primary and secondary?.
							-- if an abilty is selected (get this info from Keyboardhander / or from GG.var that it sets) then right click deselects it, and left click of course means "give the order" :D.
	else -- we expect it to be in the "GUI" / button area . Might want to do a separate check ie the complementary area to the one we checked above - and then catch in a final else (this as elseif) [and annouce via echo] to see if we're slipping up somewher
		-- so now we break down the area into more managable ones - as our buttons are not "GUI-filling", but rather there are "empty" parts of the GUi, I'd say check which "button area" we're in (can do this in simple rectangles, or in a raster approach), and then check vs. tables whether the button is hit or not (this seeming to me to be the least of a performance hit). And yes, performance issues are relavent here, from what I've heard!! (ie all GUI frameworks are FPS eaters)

			-- so
		if -- xvalue less than the middle, we're on the left
			-- now check top to bottom (just each area, the small optimisation of going halves is prob not that relevant...)
			if -- in top section (eg Minimap) (all sections just examples)
			elseif -- in 2. topmost section
				-- if we have two buttons here, then check for them (ie left or right, or 3 or 4 if there's that many)
			elseif -- in middle section
				-- then check if the button was actually clicked
				-- most efficient way to do this is table for eg. all x values and each position holding another table for all y values (each as index values - ie Xvalues[32]=table of all corresponding y values, these eg 78 = true) ? and check if a given y position at x coordinate is valid ? (maybe there's some inherent stuff we could use - but that should be easy enough to implement)
				-- if yes (it's on the button, not on empty), then pass on to GUIHandler (so that it shows the button was pressed - or is depressed, see next comment line)
				-- open question here is wheter just the MousePress leads to selecting the order, or if it's on release -> check how Warcraft or other RTS titles do it.
					-- dependent on that, either pass on order, or set value / Abilitybutton as depressed (- to be checked for in MouseRelease below)
					-- most of this should be in (a) function(s) - as we'll be doing this same thing pretty often. 
			elseif -- in 2. section from bottom
			else -- should only be the bottommost section left
			end
		else -- we're on the right
			-- see the left - same thing here
		end
	end	
end

function widget:MouseRelease() -- we need the vars actually - check what they are